Object transfer control in a communications network

ABSTRACT

A method and an intermediate component for controlling in a communications network an object transfer from a first network component via the intermediate component to a second network component which is remote from the first network component are described. The object transfer is based on a plurality of object requests relating to objects referred to in one or more codes to be processed by the second network component or another network component. The intermediate component forms the steps of sending an object request to the first network component, receiving the requested object from the first network component, updating and/or assessing a priority of the requested object, and, in dependence of the priority of the requested object, delaying the requested object or forwarding the requested object to the second network component. An initial priority is assigned to the requested objects on the basis of an analysis of at least one of the object request and the code that refers to the requested object.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention generally relates to the field of communications networksand more particularly to an object transfer from a first networkcomponent via an intermediate component to a second network component,the second network component being remote from the first networkcomponent.

2. Description of the Prior Art

The transfer of information over modern communications networks like thepublic Internet or internal networks is based on specific transferprotocols. The World Wide Web for example, which constitutes a majoraspect of the Internet, uses the Hyper Text Transfer Protocol (HTTP) forexchanging files comprising text, images, sound, video, and othercontents.

Any WWW server contains, in addition to the files it can serve, an HTTPcomponent that is designed to wait for HTTP requests and to handle themwhen they arrive. A WWW browser can be considered as an HTTP client thatis configured to send HTTP requests to WWW servers. Whenever a user ofthe browser enters a file request by either “opening” a WWW file (bytyping in a Uniform Resource Locator (URL)) or by clicking on a hypertext link, the browser builds a corresponding HTTP request for the fileand sends it to the destination address. The HTTP component in thedestination server receives the HTTP request and returns the requestedfile.

The requested file may be constituted by a Hyper Text Mark up Language(HTML) page that includes HTML code. When the browser receives the HTMLpage from the server and detects that the HTML code, which can beconsidered as an object itself, includes further objects such as(background) images, sounds, scripts or HTML frames, the browser issuesfurther HTTP requests to the server in order to fetch the furtherobjects which are included in the HTML code. Upon receipt of the furtherHTTP requests, the server sends HTTP responses including the requestedobjects like images to the browser. As becomes apparent from FIG. 1, theHTTP responses are sent from the server to the browser running on theclient in the same order as the browser has issued the HTTP requests.

The order in which any additional objects included in the HTML code ofthe HTML page are requested by the browser usually depends on how theHTML page was written. For example an object that is included at thebeginning of the HTML code is not necessarily displayed at the top ofthe HTML page because features such as tables, layers and frames allowthe HTML author to use complex layouts. In addition, the order in whicha browser issues HTTP requests depends also on internal browseralgorithms. For example some browsers use complex heuristics forgenerating the HTTP requests by starting with requesting the first fourobjects as they appear in the HTML code of the page. After the firstfour objects have been requested, every second object starting from thetop of the area that is currently visible to the user is requested, thenevery fourth object and so on. Other browsers use a simpler algorithmthat requests the objects one by one as they appear in the HTML code.From the above it becomes apparent that it is usually difficult topredict the order in which HTTP requests for objects referred to in anHTML code are generated.

Moreover, it is difficult to predict the order in which requestedobjects are received by the browser. Although the current HTTP standard(HTTP/1.1) requires that on each Transfer Control Protocol (TCP)connection the HTTP responses are sent from the server to the browser inthe same order as the HTTP requests are received by the server, theorder in which HTTP responses are received becomes unpredictable as soonas more than one connection is opened to the server. The reasontherefore is the fact that due to varying network conditions anddifferent request processing times, some connections may transfer HTTPresponses faster than others.

There is a need for a method and a device that enable an improvedtransfer of objects from a first network component to a second networkcomponent which is remote from the first network component.

SUMMARY OF THE INVENTION

According to one aspect of the invention this need is satisfied by amethod of controlling in a communications network an object transferfrom a first component via an intermediate (hardware or software)component to a second component which is remote from the firstcomponent, wherein the object transfer is based on a plurality of objectrequests relating to objects referred to in one or more codes to beprocessed by the second or another component of the communicationsnetwork and wherein the intermediate component performs the steps ofsending an object request to the first component, receiving therequested object from the first component, at least one of assessing andupdating a priority of the requested object, wherein an initial priorityhas been assigned to the requested object on the basis of an analysis ofat least one of the object request and the code that refers to therequested object, and, in dependence of the priority of the requestedobject, delaying the requested object or forwarding the requested objectto the second component. An object may itself comprise code portionsreferring to one or more further objects. Furthermore, a code may itselfform a (e.g. previously requested) object.

By intentionally delaying the object transfer based on an assignedpriority, the overall transfer of objects is improved from a user'spoint of view (even if the total amount of data to be transferred is notdecreased) because important objects are transferred preferentially.Furthermore, by implementing appropriate priority assignment schemes theobject transfer from the first network component to the second networkcomponent becomes more predictable. For example objects being of highersignificance to the user may be assigned a higher priority and may thusbe preferentially transferred to the second component. On the otherhand, objects being of lesser significance may be delayed. In theextreme case an object having a low significance may be delayed to suchan extent that it is not transferred to the second component at all.This allows to control the order in which objects are received by thesecond component.

The assignment of absolute or relative priorities to objects (or classesof objects) may be performed dynamically. Once a priority has initiallybeen assigned, this priority may be assessed with respect to specificabsolute values like thresholds or with respect to priorities of otherobjects. Based on the assessment it can be decided whether or not anobject is to be delayed. Prior to the assessment a priority initiallyassigned to an object may be evaluated anew with the purpose ofdetermining whether the initial priority has to be updated.

The intermediate component may be operated to re-order objects receivedfrom the first component. The delaying of objects is thus preferablyperformed such that the order in which the intermediate componentreceives the objects from the first component differs from the order inwhich the objects are forwarded to the second component. The reorderingmay be based on the priorities of the objects to be transferred. Duringthe reordering there might arise the situation that due to the delay ofsome objects the transfer of other objects is actually accelerated.

The object request that is sent to the first component may be generatedby the intermediate component. When the requested object is received bythe intermediate component, it “pushes” it to the second componentwithout having received an explicit object request from the secondcomponent. Alternatively, the object request may be generated by thesecond component and sent to the intermediate component. Upon receipt ofthe object request from the second component, it may be processed by theintermediate component and forwarded to the first component.

When the intermediate component receives the requested object from thefirst component, the received object may either be delayed or directlyforwarded to the second component. There exist various possibilities howthe requested object that is received by the intermediate component canbe delayed. Delaying of the requested object can for example include atleast one of instructing the second component to repeat the objectrequest, suspending a connection to the second network component viawhich the requested object is to be forwarded, and informing the secondcomponent that the requested object will automatically (e.g. without anyfurther object request from the second component) be forwarded to thesecond component at a later point in time.

If delaying of the requested object includes instructing the secondcomponent to repeat the object request, the intermediate component mayperform the steps of assigning a specific attribute to the object to bedelayed, informing the second component of the attribute, receiving areference to the attribute (e.g. the attribute Itself or an unambiguousreference derived from the attribute) from the second component, and,upon receipt of the reference to the attribute, sending the delayedobject to the second component or further delaying the delayed object.The decision whether a delayed object is to be sent to the secondcomponent or delayed further may be based on the newly assessed relativepriority of the repeatedly requested object.

The attribute can be considered as a common denominator which enablesthe intermediate component and the second component to negotiate aboutthe transfer of the object to which the attribute has been assigned.Usually, the form of the attribute will depend on the characteristics ofthe transfer protocol that is used for the object transfer. In the caseof HTTP for example, the attribute may be constituted by a virtual URLcreated by the intermediate component. It should be noted that theattribute-based delay scheme of instructing the second component torepeat the object request can generally be used to delay objects anddoes not necessarily require that priorities have been assigned to theobjects to be transferred.

In the attribute-based delay scheme the object may be send from theintermediate component to the second component in response to an objectrequest received from the second component or in accordance with apushing scheme, i.e. independently of such an object request from thesecond component. If the delay scheme is based on an object requestreceived from the second component, the second component may be informedabout the attribute in context with an instruction to repeat the objectrequest. In such a case the reference to the attribute may be receivedby the intermediate component in context with a repeated object requestfrom the second component.

The objects to be transferred to the second component may be forwardedto the second component via a single or via a plurality of connectionsbetween the intermediate component and the second component. In such amultiple connections scenario selected ones of the connections to thesecond component may be suspended dependent upon the (initial orupdated) priorities of the requested objects that are to be forwardedvia the selected ones of the connections to the second component. Theintermediate component may thus suspend one or more connections so thatobjects having a high priority can make use of the additional bandwidththat is released on the link between the intermediate component and thesecond component. In order not to waste available bandwidth theintermediate component is preferably configured such that it ensuresthat a link formed by two or more connections is fully used beforesuspending one or more connections thereof.

There exist various techniques for suspending a connection. For exampletransmission over the connection could be blocked for a specific periodof time while leaving the connection as such open (intermediatestate=open). Alternatively, the connection could be closed (intermediatestate=closed) while saving the state of the connection. In such a casethe connection may be reopened at a later point in time in the samestate in which it was closed. According to a third possibility, theconnection may be completely closed without saving any information aboutthe state of the connection. In any case the second component can beinformed that the one or more objects to be transmitted via the closedconnection will be sent later, either in response to or independentlyfrom a (repeated) object request.

Instead of or in addition to suspending individual connections, theobject transfer may also be delayed by a priority based adjustment ofthe transfer speed. To that end, a specific share of processingcapabilities may be dynamically allocated to each object or eachconnection. In the case of multiple connections, all connections or atleast some connections get a share of the CPU time, i.e. a share of thenetwork bandwidth. The share of processing capabilities allocated to aspecific connection may be changed (e.g. decreased constantly) while oneor more objects are transferred via the respective connection.

It has been mentioned above that the object transfer is based on aplurality of object requests relating to objects referred to in one ormore codes. According to a first variant of the invention a code isreadily available to at least one of the second and the intermediatecomponent. According to a second variant of the invention the code hasyet to be loaded by either one of the second and the intermediatecomponent. In the latter case the intermediate component may send a coderequest that has been generated by the second component or by theintermediate component to the first component or a third component thatis different from the first component. When the requested code isreceived from the first or the third component, it may be analyzed bythe intermediate component with respect to references to objectscomprised within the code. Any references to objects contained in thecode may then be assessed with the purpose of assigning (initial)priorities to the objects referred to in the received code. The codereceived from the first or the third component may eventually beforwarded by the intermediate component to the second component.

Upon receipt of a response from the first component the requested objectcontained in the response may be evaluated with respect to the receivedobject's priority. For example at least one of the object size, theobject content and a header of the response may be analyzed to that end.It can then be determined whether or not an initial priority of areceived object has to be updated.

Preferably, at least some information about each object or each class ofobjects is stored for example by the intermediate component. The storedinformation may comprise priority information for individual objects ora classes of objects, preferably, in the form of a priority list. Thispriority list may be repeatedly assessed. Such an assessment can relateto at least one of updating priority information and deleting objects orclasses of objects from the priority list.

The invention may be implemented as a hardware solution or as a softwaresolution. In the case of a software solution the invention may berealized in the form of a computer program product comprising programcode portions for performing the individual steps of the invention. Thecomputer program product may be stored on a computer readable recordingmedium.

According to a preferred embodiment of the invention the intermediatecomponent is implemented as a proxy component in the form of a piece ofsoftware running on the first or the second component of thecommunications network. If the invention is implemented as a hardwaresolution, the intermediate component may be constituted by a separatepiece of hardware like a proxy server arranged between the first and thesecond component in the communications network. The intermediatecomponent may include one or more appropriately configured communicationinterfaces for communicating with at least the first and the secondcomponent of the communications network as well as a unit for performingthe processing in context with delaying of objects.

In the communications network there exists a first link between theintermediate component and the first component and a second link betweenthe intermediate component and the second component. Preferably, thefirst link and the second link have different transfer rates. Forexample a fast link may be provided between the intermediate componentand the first component and a comparatively slower link may be providedbetween the intermediate component and the second component. Thissituation is usually given when the first component is a network server,the second component is a network client and the intermediate componentis located in the vicinity of (in terms of network links) or on thenetwork server. However, the intermediate component could also belocated close to (in terms of network links) or on the network client.In such a case the link between the intermediate component and thesecond component (the network client) has a much higher capacity andlower latency than the link between the intermediate component and thefirst component (the network server).

It should be noted that the invention is not restricted to the case thatthe first component acts as network server and the second component actsas network client. In particular, the intermediate component could alsobe used to improve the object transfer between two network clients ortwo network servers.

According to an especially preferred embodiment of the invention theintermediate component is part of a wireless communications network likea GSM, GPRS, etc. cellular network. In such a network the secondcomponent may be constituted by a mobile terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further aspects and advantages of the invention will become apparentupon reading the following detailed description of preferred embodimentsof the invention and upon reference to the drawings, in which:

FIG. 1 is a schematic diagram illustrating a transfer of objects betweena network server and a network client in accordance with HTTP;

FIG. 2 is a block diagram of a network system comprising an intermediatecomponent in the form of a HTTP proxy server according to the invention;

FIG. 3 is a block diagram of the HTTP proxy server of FIG. 2;

FIG. 4 is a schematic diagram depicting a redirection-based object delayin the network system depicted in FIG. 2;

FIG. 5 is a flow chart reflecting the steps preceding an object delay;

FIG. 6 is a flow chart depicting the decisions involved in an objecttransfer according to the invention; and

FIG. 7 is a block diagram depicting a proxy component according to theinvention located on a network client.

DESCRIPTION OF A PREFERRED EMBODIMENT

Although the present invention can be practiced in any communicationsnetwork in which a request-based object transfer via an intermediatecomponent is performed, the following description of preferredembodiments is exemplarily set forth with respect to the transfer ofHTML code in accordance with the HTTP protocol over the WWW. Inprinciple, transfer protocols different from HTTP, like the wireless WAPtransport protocol or some Remote Procedure Call (RPC) mechanisms, andcodes different from HTML, for example the WAP Markup-Language (WML) orany derivatives of the extensible Markup-Language (XML), could beutilized as well. Furthermore, although the following description mainlyconcerns an object transfer from a server to a client, the objecttransfer could be performed between any two or more network components.

In FIG. 2, a block diagram of a network system 10 according to theinvention is depicted. As becomes apparent from FIG. 2, the networksystem 10 comprises a first component in the form of a server 20, anintermediate component in the form of a HTTP proxy server 30 and asecond component in the form of a client 40. The proxy server 30 isarranged in the network system 10 such that it has a fast link 12towards the server 20 and a comparatively slower link 14 towards theclient 40. Each link 12, 14 is constituted by a plurality of TCPconnections 50. Each TCP connection 50 is configured to allow thetransfer of HTTP requests and HTTP responses between the server 20 andthe client 40.

The proxy server 30 performs some traditional proxy functions likecaching and filtering of objects. Additionally, the proxy server 30 isconfigured to artificially delay an object that is received from theserver 20 and that is to be forwarded to the client 40. This is done byusing a combination of temporary suspension of data transfer on someconnections 50 and HTTP redirection messages that force a browserrunning on the client 40 to repeat an object requested after a certainperiod of time. By using these mechanisms the proxy server 30 re-ordersthe HTTP responses received from the server 20 in such a way thatobjects having a higher priority are delivered to the client 40 first.For that purpose the proxy server 30 dynamically assigns priorities tothe objects to be forwarded to the client 40. In order to ensure thatdelaying of the less important objects does not cause the link 14between the proxy server 30 and the client 40 to become idle, the proxyserver 30 continuously or at least repeatedly monitors the traffic onthis link 14.

The construction of the proxy server 30 is depicted in more detail inFIG. 3. As becomes apparent from FIG. 3, the proxy server 30 comprises acommunications interface 32 coupled between the first link 12 to theserver 20 and the second link 14 to the client 40. The communicationsinterface 32 is configured such that it enables the sending of objectrequests to and the receipt of the requested objects from the server 20.A processing unit 34 of the proxy server 30 communicates with thecommunications interface 32. The processing unit 34 allows to assessand/or adapt the priority of any object received via the first link 12from the server 20. Additionally, the processing unit 34 allows toassign an initial priority to a requested object on the basis of ananalysis of at least one of the object request and the code that refersto the requested object. Possible assignment schemes will be discussedlater in more detail.

In dependence of the initial or updated priority of an requested objectthe processing unit 34 controls the communications interface 32 suchthat a requested object received from the server 20 is either delayed orforwarded via the second link 14 to the client 40. If a requested objectreceived from the server 20 is to be delayed, it is temporarily storedin a buffer 36 that can be accessed by both the communications interface32 and the processing unit 34. Alternatively or in addition, the buffer36 may be implemented as a software or hardware component of theprocessing unit 34.

Besides the tasks outlined above, the processing unit 34 is additionallyconfigured such that it allows to assign a specific attribute to anobject which is to be delayed (an exemplary format of this attributewill be discussed later in more detail). The processing unit 34 enablesto control the communications interface 32 such that the communicationsinterface 32 informs the client 40 about this attribute. If thecommunications interface 32 receives a reference to the attribute fromthe client 40, the processing unit 34 evaluates this reference andcontrols the communications interface 32 such that the delayed object towhich this attribute has previously been assigned and which is currentlystored in the buffer 36 is either sent to the client 40 or furtherdelayed. A further delay of the object stored in the buffer 36 maybecome necessary if objects of a higher priority have to be forwarded tothe client 40 first.

In the following, a preferred operational mode of the network system 10shown in FIG. 2 will exemplarily be described.

When a user enters a URL, clicks on a link or follows a bookmark, thebrowser running on the client 40 issues a HTTP request for thecorresponding HTML page including HTML code. The HTTP request issued bythe browser is received by the proxy server 30 via the link 14 andforwarded via the link 12 to the destination server 20. The server 20replies by sending the HTML code for the requested page to the proxyserver 30, which analyzes the HTML code received from the server 20 toassign an initial priority to any kind of objects like links, frames,scripts, images, etc. referred to in the HTML code (first analysisphase).

Independently from this analysis of the HTML code, the proxy server 30forwards the HTML code via the link 14 to the client 40. When thebrowser running on the client 40 receives the HTML page including theHTML code it processes the HTML code. If the browser detects that theHTML code includes further objects, it issues further HTTP requests forthe objects referred to in the HTML code. These HTTP requests forfurther objects are received and evaluated by the proxy server 30. Tomost of the requested objects an initial priority will have beenassigned already during the proxy server's 30 previous analysis of theHTML code that it has forwarded to the server 40. However, in thissecond analysis phase the proxy server 30 either assigns initialpriorities to those objects to which a priority has not yet beenassigned or updates the priority of such objects to which an initialpriority has already been assigned. The priority is updated on the basisof additional information available in the HTTP request received fromthe client 40.

The proxy server 30 forwards any HTTP requests for additional objectsreceived from the client 40 to the server 20. The server 20 replies bysending the requested objects to the proxy server 30. The proxy server30 analyzes the HTTP responses (including the requested objects) fromthe server 20 in a third analysis phase and updates—if necessary thepriorities of the objects comprised in the HTTP response. Additionally,the proxy server 30 assesses the relative priority of any receivedobject with respect to the priority of previously received objects thatare still stored in the buffer 36 (see FIG. 3) and the priorities ofobjects that are expected soon. Information regarding the objects thatwill be received soon from the server 20 can be derived from the HTMLcode that has previously been forwarded to the client 40 or from HTTPrequests from the client 40 for which the corresponding objects have notyet been received from the server 20. Alternatively or additionally, theproxy server 30 may be configured such that it compares a priority of anobject that has just been received from the server 40 with an absolutevalue like a priority threshold.

Based on the evaluation of an object's absolute and/or relative priorityand the current and/or predicted traffic on the link 14, the proxyserver 30 decides if this object is to be delayed, e.g. if this objectis to be temporarily stored in the buffer 36 or if the correspondingHTTP request is not yet to be forwarded to the server 20, or if theobject is to be immediately forwarded to the client 40.

The intentional delay of individual objects improves the overall objecttransfer from a user's point of view. It is for example well known thatthe relative importance of the various objects included in a web pagevaries greatly: An image that is used to build a graphical menu may beessential for the navigation of a site, while a background image merelymakes the page look nicer. The invention can thus be employed to providethe user with the more important information first. As soon as there isenough information of a web page displayed on the user's screen, theuser can decide to click on a link and request another web page withouthaving to wait for the remaining (less important) parts of the previousweb page that is still being transferred. As a result, the user is nolonger forced to wait until some uninteresting objects are transferredbefore being able to see the important ones. This is especially usefulin conjunction with the mobile Internet, which is usually slower andmore expensive than the fixed Internet.

Assignment and Adjustment of Priorities

As has become apparent from the above, the proxy server 30 can assign oradjust the priority of an object to be sent to the client 20 duringthree different phases, namely when a reference to that object is foundin an HTML code (i.e. in a previous object) that is to be forwarded tothe client 40, when a HTTP request relating to that object is issued bythe browser running on the client 40, or when the corresponding HTTPresponse containing the requested object is received from the server 20.

In the following, various schemes for assigning or updating prioritiesduring each of these three phases are exemplarily described. During anyof the three phases a priority list that contains priority informationfor individual objects or classes of objects is either generated orupdated. In the priority list, the individual objects or classes ofobjects are ordered with respect to increasing or decreasing priority.The order of the objects in the priority list can thus be considered aspriority information. However, additional priority information likeabsolute or relative priority values (numbers) may alternatively oradditionally be part of the priority list.

The exact priority assigned to specific objects or classes of objects isimplementation-dependent and in the exemplary embodiment configurable bythe operator of the proxy server 30 or a user of the browser running onthe client 40. For example in order to allow the operator of the proxyserver 20 to have more control over the priority of some objects, therecould be one or several lists of URLs (using pattern matching) thatallow the operator to increase or decrease the priority of the objectsappearing on those lists. For example an operator could decide toincrease or decrease priority of all images downloaded from anadvertising company. The same possibilities may be made available to theuser. For example the user could send his preferences to the proxyserver 30. This can be done by a specific software running on the client40 or by using designated web pages provided directly by the proxyserver 30 and allowing the user to set his preferences.

In the first analyzing phase the proxy server 30 can assign an initialpriority to an object by analyzing an HTML code that has been requestedby the client 40 from the server 20. In particular, references toobjects referred to in the HTML code may be assessed to that end. Inthis way a priority list may be generated that lists individual objectswhich are referred to in the HTML code in the following order (objectsof highest priority are mentioned first):

-   -   links to other pages    -   frames    -   inlined images (if the IMG tag includes width and height        information, this information can be used to refine the priority        of images depending on the expected dimensions so that smaller        images get a higher priority than larger ones)    -   style sheets    -   scripts (JavaScript, VBScript, etc.), embedded objects and        applets    -   background image (page background, table background, style        sheet, etc.)    -   any object that was already sent to the client 40 gets the        lowest priority

In addition the priority of a specific object can be lowered if theobject is not located on the same server 20 or on the same domain as thecurrent HTML page.

A further possibility to assign or adjust the priority of an objectoccurs when a request for that object is issued by the browser andreceived by the proxy server 30. In such a case the HTTP request can beanalyzed by the proxy server 30 in an URL context (second analysisphase). Since initial priorities have already been assigned duringanalysis of the HTML code that led to that HTTP request, analysis of theHTTP request will usually result in an adjustment of the initialpriority. However, in some cases initial priorities may be assigned also(see above).

The adjustment or assignment of initial priorities in the secondanalysis phase can be performed in dependence on additional informationavailable for example in the header of the HTTP request. One or more ofthe following rules for updating the priorities may be implemented:

-   -   The analysis leads to the result that the browser has already        requested the same object once. Such an object is preferably        assigned a very high priority in order to avoid infinite loops        caused by browsers that are not fully compliant to HTTP/1.1 and        ignore the Retry-After header (this header will be discussed        below in more detail).    -   The object does not have a priority yet, but the file extension        looks like HTML (“.HTML”,“.HTM”) or XML (“.XML”) or looks like a        directory index (ends“/”). Such a priority assignment ensures        that a HTML page requested from the bookmarks or typed in        directly will be requested with a high priority.    -   The browser makes a conditional HTTP request for an object,        using if-modified-since or similar conditions. This indicates        that the browser has probably cached a copy of the object. The        reply is expected to be small if the cached copy is still valid        (HTTP reply code “304 not modified”).    -   The URL of the requested object was found while parsing a        previous HTML page.    -   Any object that was not inserted in the list while parsing the        HTML tags of a previous page was probably requested indirectly        by a script and should get a lower priority than most of the        other requested objects.

In the third analysis phase, the adjustment of object priorities isbased on an analysis of the HTTP response from the server 20. Theadjustment of the priorities in the third analysis phase (as well as inthe second analysis phase mentioned above) can be calculated as aweighted sum of several criteria. The weights may be configurable by theoperator of the proxy server 30 or the user of the browser running onthe client 40.

In the third analysis phase, all objects will usually have a priorityassigned to them. However, this priority can be updated before sendingthe requested objects to the client 40. To adjust the priorities, theheaders and contents of the HTTP responses received from the server 20may be assessed. The priorities may then be adjusted in accordance withone or more of the following rules:

-   -   Assessment of the reply code: the relative priority of the HTTP        responses depends on the first digit of the reply code. Error        codes (4xx, 5xx) should have a higher priority than normal        replies (2xx).    -   Assessment of the content type: a HTML code should have a higher        priority than any image.    -   Assessment of the objects size (derived from the content-length        if specified in the headers, or from the total size if the        object is already cached): smaller objects should have a        slightly higher priority than larger ones.    -   Analysis of the content: for example animated images can be        assigned a lower priority than static images. The analysis of        the content can also form the basis for estimating the size of        the object if this information is not available in the HTTP        header and the object has not yet been cached.    -   If the reply code is a permanent or temporary redirection (3xx)        specifying a new location for the requested object, then this        new location gets the same priority as the original object.

In the three analysis phases described above the proxy server 30 setsand updates the priorities of the objects that are to be transferred tothe client 40. The proxy server 30 thus keeps some information abouteach object like the object's URL, priority, time of last request and,if required, some further parameters. However, this information can notbe kept forever since otherwise the proxy server 30 would run out ofmemory. Moreover, if an object to which a high priority has beenassigned is never requested, action is preferably taken so that it doesnot prevent other objects from being transferred.

For these reasons a routine is implemented that ensures that informationthat is no longer up to date or that is no longer required is deleted.To that end one or more of the following mechanisms may be used:

-   -   Any object that is successfully transferred to the client is        marked as having been sent or is moved to a separate list of        objects that have been sent to the client 40.    -   A maximum size for one or more lists containing relevant        information is set and configured such that older objects or        objects with the lowest priority expire first.    -   Whenever the client resets a TCP connection before the object is        fully transferred (meaning that the user has stopped the        download and may have selected another page), clear the        information of objects to be sent.    -   As an alternative to the previous solution, keep        cross-references for each object in order to associate each HTML        page with the objects that it contains and vice versa. When the        client 40 resets a TCP connection, remove only the objects that        are included in the same HTML page.    -   The priority of all objects can be decreased after a specified        amount of time or after some number of HTTP requests or HTTP        responses have been processed.

Reordering of Objects

In the previous chapter the generation of a priority list for therequested objects to be transferred to the client 40 as well as possibleupdating mechanisms for this priority list have been described. Usually,the requested objects will be received by the proxy server 30 from theserver 20 in an order that is different from the order indicated in thepriority list. Consequently, the proxy server 30 has to reorder theobjects received from the server 20 in such a manner that they areforwarded from the proxy server 30 to the client 40 in an order whichreflects the order in the priority list as closely as possible. Theproxy server 30 reorders the objects received from the server 20 byintentionally delaying objects having a lower priority and by forwardingobjects having a higher priority without any substantial delay to theclient 40.

The proxy server 30 uses a combination of different delay mechanisms toreorder the objects received from the server 20. In the following, twoof these delay mechanisms, namely suspension of TCP connections on theone hand and HTTP redirections on the other hand, will exemplarily bedescribed in more detail

Suspension of TCP Connections

As becomes apparent from FIG. 2, the link 14 between the proxy server 30and the client 40 is constituted by a plurality of TCP connections 50.Dependent upon the priorities of the requested objects that are to beforwarded via individual ones of the connections 50, one or more of theconnections 50 that are intended for the transfer of objects having alow priority are suspended. This suspension of individual connectionsreleases some bandwidth on the link 14 that is now available forpreferentially transferring objects having a higher priority.Consequently, objects having a higher priority will be delivered beforeobjects having a lower priority.

The suspension of an individual connection 50 is performed such that theconnection 50 is left open without transferring objects for a certainperiod of time. Alternatively, suspension of a connection 50 could beeffected by closing the connection 50, either with our without savingthe state of the connection 50 prior to its suspension. When the stateof the suspended connection 50 is saved, it can be opened at a laterpoint in time in the same state as it has been suspended (i.e. closed).

Suspension of a connection 50 has the advantage that no extra data hasto be sent via the link 14. Preferably, a connection 50 is suspendedonly if the released bandwidth can be fully used by some otherconnections 50 for the transfer of objects having a high priority.

The proxy server 30 is thus configured such that it checks that the link14 is fully used before suspending a connection 50 in order not to wasteavailable bandwidth. A possible routine for predicting if the link 14 isor will be partially idle includes comparing the average throughput(over the last N seconds) of all connections 50 going to the client 40with the amount of data that is currently cached or buffered in thebuffer 36 of the proxy server 30 (see FIG. 3) and is ready to be sent.Other and in particular simpler techniques for estimating theutilization of the link 14 could be implemented as well, especially ifthe available bandwidth on the link 14 is known by other means.

HTTP Redirections

If the proxy server 30 expects that objects having a high priority willsoon have to be transferred to the client 14 (e.g. because links tothese objects have previously been detected by the proxy server 30 whileforwarding the HTML code of a HTML page to the client 40), andsuspension of a connection 50 would waste some bandwidth because thereis currently nothing else to transfer on the other connections 50, thenthe proxy server 30 may utilize another delay scheme. A possible delayscheme that is applicable in such a case includes instructing the client40 to repeat an object request at a later point in time.

Although HTTP specifies that any HTTP responses must be sent to theclient 40 in the same order as the browser running on the client 40 hasissued the HTTP requests, it is possible to instruct the browser toretry a HTTP request later. This can be done by sending a HTTP responsewith the status code “302” to the client 40, together with the headerfield “Retry-After”. This header field tells the client 40 to retry hisHTTP request after a specified amount of time. In response to thereceipt of the status code “302” (possibly including the “Retry-After”header field), current browsers re-schedule the HTTP request after allpending HTTP requests have been processed.

The status code “302” as specified in the HTTP standard 1.1 tells thebrowser that a given object can be found (temporarily) at a locationthat is different from the one that was requested. The HTTP responsesent to the client 40 includes the new location of the object. Thismechanism is used to implement the delay scheme according to theinvention.

According to the invention the proxy server 30 generates an attribute inthe form of a new (virtual) URL for the object to be delayed. The proxyserver 30 then instructs the browser running on the client 40 to try theHTTP request again, using this temporary attribute (i.e. URL) as the newlocation of the object. The browser is thus instructed to re-schedulethe HTTP request at a later point in time. When the browser repeats itsHTTP request (including the temporary attribute, i.e. the virtual URL),the proxy server 30 converts the attribute to the original URL andforwards the HTTP request to the server 20. Alternatively, the originalHTTP request could have been forwarded to the server 20 after receiptthereof by the proxy server 30. In such a case the HTTP responsereceived from the server 20 is temporarily stored by the proxy server 30until it receives the repeated HTTP request from the client 40.

In the following, the inventive delay mechanism discussed above willexemplarily be described in more detail with reference to FIGS. 4 and 5.It will be assumed that the HTTP request received by the proxy server 30from the client 40 relates to an object that is considered by the proxyserver 30 to be of a low priority.

In a first step 402 of FIG. 4, the proxy server 30 receives a HTTPrequest from the client 40 via the link 14. In the exemplary case ofHTTP this first request from the client could have the following format:

-   -   GET http://example.com/some/image.png HTTP/1.1    -   Host: example.com    -   User-Agent: Mozilla/5.0 (X11; Linux i686; en-US; rv: 0.9.9)    -   Gecko/20020311    -   Connection: close

In response to the HTTP request received in step 402 from the client 40,the proxy server 30 redirects the client 40 in step 404 to a new(virtual) location and instructs the client 40 to wait for a certainperiod of time (delay) before retrying the HTM request. The redirectionmessage from the proxy server 30 on the basis of the status code “302”as specified in the HTTP standard 1.1 can have the following format:

-   -   HTTP/1.1 302 Found    -   Date: Thu, 21 Mar. 2002 15:12:47    -   Server: PrioTest/0.9    -   Location: http//example.com/some/( )image(0001).png    -   Retry-After: 5    -   Connection: close    -   Transfer-Encoding: chunked    -   Content-Type: text/html; charset=iso-8859-1    -   (some human-readable text follows)

The proxy server 30 can now request the object from the server 20 at anytime after receipt of the initial HTTP request from the client 40 (step402) and the time at which it decides to deliver the object to theclient 40 (steps 406 and 408).

After receipt of the above redirection message the client 40 waits for aperiod of time specified in the redirection message, i.e. five seconds(or until all other objects have been transferred). In step 412 theclient 40 then repeats his HTTP request indicating the new (virtual)location as follows:

-   -   GET http://example.com/some/( )image(00001).png HTTP/1.1    -   Host: example.com    -   User-Agent: Mozilla/5.0 (X11; Linux i686; en-US; rv:0.9.9)    -   Gecko/20020311    -   Connection: close

Upon receipt of the repeated HTTP request from the client 40, the proxyserver 30 decides whether to delay the requested object further (e.g. bysuspending a connection 50 or by a further redirection message) orwhether to forward the delayed object to the client 40. If the proxyserver 30 decides to forward the delayed object without any furtherdelay, this can be done in the following format:

-   -   HTTP/1.1 200 OK    -   Date: Thu, 21 Mar. 2002 15:12:50    -   Server: Apache/1.3.23 (Unix)    -   Content-Type: image/png    -   Content-Length: 1520    -   (the contents of the image follow)

Now, the decisions taken by the proxy server 30 in the course of theredirection routine discussed above with reference to FIG. 4 will beexplained with reference to FIG. 5.

In step 502 the proxy server 30 receives the HTTP request from theclient 40. In the following step 504 the proxy server 30 determineswhether the URL included in the HTTP request is a modified URL, i.e. theresult of a previous redirection. If this is the case, the proxy server30 decodes the URL and restores the original location in step 506 andmoves via node 508 to step 510. Otherwise the method directly moves fromstep 504 via node 508 to step 510.

In step 510 the proxy server 30 determines if the object requested bymeans of the HTTP request is already available, i.e. stored in thebuffer 36 of the proxy server 30 (see FIG. 3). If the object is notalready cached, the proxy server 30 requests the object from the server20 or marks it for later retrieval in step 514. From step 514 the methodmoves via node 512 to step 516. Step 516 can also be reached directlyfrom step 510 via node 512 in the case the object requested by theclient 40 is already available.

In step 516 the HTTP response including the requested object is ready tobe sent to the client 40. This corresponds to the first step in the flowchart of FIG. 6 which will be discussed below.

In principle, the redirection message (step 404 in FIG. 4) can be sentto the client 40 at any time while steps 502 to 516 are performed orafter step 516. It should be noted that the availability of an object(i.e. whether a requested object is already cached, currently intransfer or whether the object is not requested yet) is a further factorthat influences the initial priority of a requested object.

Re-Ordering Decisions

Once the HTTP response is ready to be sent to the client 40 (step 516 inFIG. 5), it has to be decided if an object comprised in the HTTPresponse should actually be delivered to the client 40, if the client 40should be redirected or if the connection 50 via which this object is tobe sent to the client 40 should be suspended. A flow chart depicting anexemplary decision scheme in this regard is depicted in FIG. 6.

In step 602 the HTTP response is ready to be sent to the client. In thefollowing step 604 the priority of this object is evaluated with respectto the fact whether or not the priority has to be updated. If thepriority of the object has to be updated, the priority is adjusted instep 604.

In the next step 606 the current priority of the object is assessed tofind out if it has the highest priority of all objects that are beingtransferred or that are expected soon. If it is determined In step 606that the requested object actually has the highest priority, the methodmoves via node 610 to step 612. In step 612 the requested object is sentto the client 40.

If the comparison of the priority of the currently requested object withthe priority of other objects in step 606 leads to the result that thecurrently requested object does not have the highest priority, themethod continues with step 614. With respect to step 606 it should benoted that instead of comparing the priority of the currently requestedobject with the priorities of other objects it is also possible tocompare the priority of the currently requested object with a fixedthreshold or to add an offset in the comparison so that two prioritieshave to be different by more than a predefined threshold before thedifference is considered significant enough.

In step 614 the proxy server 30 estimates if the link 14 to the client40 (see FIG. 2) is or will be idle. As explained above, there areseveral ways to do that. One of them comprises calculating a runningaverage of the maximum amount of data that was sent and acknowledgedduring the last N seconds over all connections 50 going to the sameclient 40. This gives an estimate of the maximum throughput available.

The result thus obtained is then compared with the amount of data thatis ready to be sent on the connections 50 that are not suspended. If theproxy server 30 detects that it does not have enough data to send inorder to fill the link during at least one complete round-trip time,then it considers that there is some spare bandwidth on the link 14towards the client 40 and continues with step 616.

In step 616 a comparison similar to that of step 606 is performed. If itis determined in step 616 that the currently requested object has ahigher priority than all objects expected soon, the proxy server 30continues via node 610 with step 612 and sends the currently requestedobject immediately to the client 40. Otherwise the method continues withstep 618 and a redirection message (status code “302”) is sent to theclient 40 as discussed above in conjunction with FIG. 4.

The decision taken in step 616 can be influenced by the size of thecurrently requested object (if it is already known). If the object isknown to be small (e.g. less than twice the size of a redirectionmessage), then the proxy server will always send the object instead ofsending a redirection message, even if the object had been assigned avery low priority until then (this can be considered as one way ofupdating the priority).

If it is determined in step 614 that there is enough data to be sent inorder to fill the link 14, the method continues with step 620 andsuspends the connection 50 to the client 40 via which the currentlyrequested object is to be transferred.

From either one of step 612, 618 and 620 the method continuous with step622. In step 622 the proxy server 30 re-evaluates all suspendedconnections 50 to find out whether any one of the suspended connections50 are to be opened again.

The HTTP/1.1 protocol supports the pipelining option, which allows theclient 40 to send several requests to the server 20 or proxy server 30on the same TCP connection without waiting for the previous replies. Inthe case pipelining is used, more than one object that is ready to besent could be sent on the same connection 50 towards the client 40. Itis apparent that in such a case an object having a low priority couldblock a second object having a high priority that is to be sent on thesame connection 50. If there are several objects waiting on the sameconnection 50, the maximum or average priority of these objects may bedetermined and considered in steps 606 and 616. This ensures thatobjects of lower priority do not block objects of higher priority.

Possible Extensions

Several extensions, some of which have already briefly been discussed,to the exemplary embodiment described with reference to FIGS. 1 to 6could be implemented.

One of these extension relates to constraining the transfer speed onlink 14 in dependence of the priority of the objects to be transferred.This could be done for example by allocating a specific share ofprocessing capabilities to each connection 50 depending on the priorityof the objects to be transferred. The priority of the individual objectsis decreased while the process is running. If the proxy server 30processes connections 50 in a round-robin fashion, this feature can beimplemented by limiting the amount of data transferred per round on eachconnection 50 by a number that is derived from the priority of thatobject. The dynamic allocation of processing capabilities canadvantageously be combined with the suspension and redirectionmechanisms discussed above. The processing capabilities can also includeany transformation of the objects or codes being transferred.

According to a further extension of the invention, the priorities areassigned directly by the browser running on the client 40. The browsercan then schedule the HTTP requests for individual objects according totheir priority. If the priorities are assigned directly by the browser,there are some additional factors that can be used for refining thepriority of each object:

-   -   position of the object in the page (coordinates)    -   relative position of the visible area (objects that are outside        the visible area have a lower priority)    -   if image loading or script execution is disabled, the browser        knows immediately that it is not necessary to assign a priority        to these objects.

Additionally, the browser knows when a user selects a new HTML page fromthe bookmarks or by typing in a new URL. The browser can thus clear thelist of objects that are no longer required.

A further extension of the invention relates to a proxy component thatis located on the same computer (client) as the browser or close to thiscomputer in terms of network links. This situation is depicted in FIG.7.

As becomes apparent from FIG. 7, the client 40 not only comprises abrowser component 42 but an additional proxy component 30 (having thestructure shown in FIG. 3) in communication with the browser component42. In such a case the link 14 between the proxy component 30 and thebrowser component 42 has a much higher capacity and lower latency thanthe link 12 between the proxy component and the server 20 (not depictedin FIG. 7).

As a result, the client-side proxy component 30 influences the requeststream because it cannot do much on the response stream. Based on thepriority information derived from the current HTTP request and previousHTTP responses (e.g. previous HTML codes referring to further objects)as well as an estimate of the link availability, the client-side proxycomponent 30 will decide if a HTTP request should be forwarded to theserver and/or if it should reply immediately with a redirection message.

The decisions to be taken are simpler than depicted in the flow chart ofFIG. 6. More particularly, the decisions can be reduced to evaluating ifthe currently requested object has a lower priority than some of theobjects being transferred or expected to be transferred soon and if thelink is already fully used. If both conditions are given, then aredirection message is sent to the browser component 42. In all othercases, the HTTP request is immediately forwarded to the server.

If HTTP pipelining is used on a specific connection and if some previousHTTP requests are being processed, then the client-side proxy component30 can suspend the HTTP request until it can take the decision. It willhave to take a decision at the latest when the previous objects havebeen fully received.

A still further extension of the invention relates to the blocking ofdownloads for some objects based on their priority. This means that thepriority that is assigned to the objects can also be used to block theobjects completely. If a threshold on the priority has been set, anyobject that has a priority that is lower than this threshold will not besent to the client 40. In this case the proxy server (or proxycomponent) 30 would simply return one of the “4xx” or “5xx” status codesdefined in the HTTP/1.1 standard to the client 40 when it detects suchan object. Possible status codes are “403 forbidden”, “409 conflict” or“503 service unavailable”.

As an additional extension the priorities assigned to the objects couldbe used for pre-fetching. A pre-fetching mechanism allows the proxyserver 30 to fill its buffer 36 (see FIG. 3) with some objects beforethe client 40 actually requests them. Such a pre-fetching mechanism mayfor example be based on the analysis of a HTML code that is sent fromthe proxy server 30 to the client 40 and that includes references tofurther objects. Based on the analysis of the references to the objectsthe proxy component 30 assigns priorities to the individual objects andon the basis of this assignment it is defined which objects are to bepre-fetched and in what order. Preferably, the objects are pre-fetchedstarting with the objects having the highest priority.

According to a still further extension that may be combined with thepre-fetching mechanism discussed above, specific pushing schemes areimplemented that allow to transfer objects from the proxy server 30 tothe client 40 without having received an explicit object request fromthe client 40.

Various modifications of the preferred embodiment are possible withoutdeparting from the scope and spirit of the present invention. Althoughthe invention has been described in connection with a preferredembodiment, it is to be understood that this description is not intendedto limit the invention thereto. Rather, the invention is intended tocover all modifications and/or additions to the above-mentioneddescription, without departing from the spirit and the scope of theinvention.

1. A method, in a communications network, of controlling an objecttransfer from a first component via an intermediate component to asecond component which is remote from the first component, wherein theobject transfer is based on a plurality of object requests relating toobjects referred to in one or more codes to be processed by the secondor another component of the communications network, the intermediatecomponent performing the steps of: sending an object request to thefirst component; receiving the requested object from the firstcomponent; assessing or updating a priority of the requested object,wherein an initial priority has been assigned to the requested object onthe basis of an analysis of at least one of the object request and thecode that refers to the requested object; and in dependence of thepriority of the requested object, delaying the requested object orforwarding the requested object to the second component.
 2. The methodof claim 1, wherein the delaying is performed such that the order inwhich the objects are received from the first component differs from theorder in which the objects are forwarded to the second component.
 3. Themethod of claim 1, wherein the object request is received from thesecond component or generated by the intermediate component.
 4. Themethod of claim 1, wherein delaying of the requested object includes atleast one of instructing the second component to repeat the objectrequest, suspending a connection to the second component via which therequested object is to be forwarded, and informing the second componentthat the requested object will automatically be forwarded at a laterpoint in time.
 5. The method of claim 3, wherein instructing the secondcomponent to repeat the object request includes: assigning a specificattribute to the object to be delayed; informing the second component ofthe attribute; receiving a reference to the attribute from the secondcomponent; and upon receipt of the reference to the attribute, sendingthe delayed object to the second component or further delaying thedelayed object.
 6. The method of claim 1, wherein requested objects areforwarded via a plurality of connections to the second component.
 7. Themethod of claim 6, wherein selected ones of the connections to thesecond component are suspended dependent upon the priorities of therequested objects that were received from the first component and thatare to be forwarded via the selected ones of the connections.
 8. Themethod of claim 6, wherein to each connection a specific share ofprocessing capabilities is dynamically allocated.
 9. The method of claim1, further comprising: sending a code request to the first or a thirdcomponent; receiving the requested code from the first or the thirdcomponent; analyzing the received code with respect to references toobjects; assessing the references to objects with the purpose ofassigning initial priorities to the objects referred to in the receivedcode.
 10. The method of claim 1, wherein upon receipt of a responsecontaining the object requested from the first component, the responseis evaluated with respect to the received object's priority in order todetermine whether or not the initial priority of the received object hasto be updated.
 11. The method of claim 1, further comprising generatinga priority list that contains priority information for individualobjects or classes of objects.
 12. The method of claim 11, furthercomprising repeatedly assessing the priority list with respect to atleast one of updating priority information, deleting objects or classesof objects and corresponding information, from the priority list. 13.The method of claim 1, wherein the steps are performed by a proxycomponent situated on the first component, on the second component orconfigured as a separate hardware component of the communicationsnetwork.
 14. A method of delaying in a communications network an objecttransfer from a first component via an intermediate component to asecond component, which is remote from the first component, wherein theobject transfer is based on a plurality of object requests relating toobjects referred to in one or more codes to be processed by the secondor another component of the communications network, the intermediatecomponent performing the steps of: assigning a specific attribute to anobject which is to be delayed; informing the second component about theattribute; receiving a reference to the attribute from the secondcomponent; and upon receipt of the reference to the attribute, sendingthe delayed object to which the attribute has been assigned to thesecond component or further delaying the delayed object.
 15. The methodof claim 14, wherein the object is sent to the second component inaccordance with a pushing scheme or in response to an object requestreceived from the second component.
 16. The method of claim 15 whereinthe second component is informed about the attribute in context with aninstruction to repeat the object request and wherein the reference tothe attribute is received from the second component in context with arepeated object request.
 17. A computer program product in a computerusable medium for controlling an object transfer from a first componentto a second component via an intermediate component, the computerprogram product comprising: instructions for sending an object requestto the first component; instructions for receiving the requested objectfrom the first component; instructions for assessing and updating apriority of the requested object, wherein an initial priority has beenassigned to the requested object on the basis of an analysis of at leastone of the object request and the code that refers to the requestedobject; and in dependence of the priority of the requested object,instructions for delaying the requested object or forwarding therequested object to the second component.
 18. The computer programproduct of claim 17, stored on a computer readable medium, furthercomprising; assigning a specific attribute to an object which is to bedelayed; informing the second component about the attribute; receiving areference to the attribute from the second component; and upon receiptof the reference to the attribute, sending the delayed object to whichthe attribute has been assigned to the second component or furtherdelaying the delayed object.
 19. An intermediate component forcontrolling in a communications network an object transfer from a firstcomponent via the intermediate component to a second component which isremote from the first component, wherein the object transfer is based ona plurality of object requests relating to objects referred to in one ormore codes to be processed by the second component of the communicationsnetwork, the intermediate component comprising: a communicationsinterface for sending an object request to the first component and forreceiving the requested object from the first component; a processingunit for assessing or updating a priority of the requested object,wherein an initial priority has been assigned to the requested object onthe basis of an analysis of at least one of the object request and thecode that refers to the requested object, and wherein the processingunit in dependence of the priority of the requested object delays therequested object or controls the communications interface to forward therequested object to the second component.
 20. An intermediate componentfor delaying in a communications network an object transfer from a firstcomponent via the intermediate component to a second component which isremote from the first component, wherein the object transfer is based ona plurality of object requests relating to objects referred to in one ormore codes to be processed by the second component of the communicationnetwork, the intermediate component comprising: a processing unit forassigning a specific attribute to an object which is to be delayed, anda communications interface for informing the second component about theattribute, for receiving a reference to the attribute from the secondcomponent and, upon receipt of the reference to the attribute, forsending the delayed object to which the attribute has been assigned tothe second component B or further delaying the delayed object.
 21. Theintermediate component of claim 20, configured as a proxy server.
 22. Anetwork system comprising an intermediate component for controlling anobject transfer from a first component via the intermediate component toa second component which is remote from the first component, wherein theobject transfer is based on a plurality of object requests relating toobjects referred to in one or more codes to be processed by the secondcomponent of the communication network, the intermediate componentcomprising: a processing unit for assigning a specific attribute to anobject which is to be delayed and a communications interface forinforming the second component about the attribute, for receiving areference to the attribute from the second component and, upon receiptof the reference to the attribute, for sending the delayed object towhich the attribute has been assigned to the second component or furtherdelaying the delayed object.
 23. The network system of claim 22, furthercomprising a first link between the intermediate component and the firstcomponent and a second link between the intermediate component and thesecond component, wherein the first link and the second link havedifferent transfer rates.
 24. The network system of claim 22, comprisinga second component in the form of a mobile terminal.